Conversation
Add Step 1.5 to plan-feature that optionally links a Feature to a parent issue (e.g., Outcome) in the Jira hierarchy. Validates that the parent's hierarchyLevel is strictly higher than the Feature's before setting the link. Includes REST API fallback and a new constraint (1.82) in docs/constraints.md. Implements TC-4870 Assisted-by: Claude Code
Reviewer's GuideAdds an optional Step 1.5 to plan-feature for linking a Feature to a valid higher-level parent issue in Jira, wires this step into the JIRA access and REST fallback workflow, and records the hierarchy validation requirement as a new documented constraint with traceability updates. Sequence diagram for new Step 1.5 Feature parent linking workflowsequenceDiagram
actor User
participant PlanFeatureSkill
participant Jira
User->>PlanFeatureSkill: invoke plan-feature
PlanFeatureSkill->>Jira: jira.get_issue(feature_key) (Step1)
Jira-->>PlanFeatureSkill: Feature issue (includes parent, hierarchyLevel)
PlanFeatureSkill->>PlanFeatureSkill: [check Feature.parent]
alt Feature already has parent
PlanFeatureSkill->>User: show current parent and ask keep_or_change
opt user keeps parent
PlanFeatureSkill->>User: proceed to Step2
end
opt user changes parent
PlanFeatureSkill->>User: prompt for parent issue key or Enter to skip
end
else no existing parent
PlanFeatureSkill->>User: prompt for parent issue key or Enter to skip
end
alt User provides parent_key
PlanFeatureSkill->>Jira: jira.get_issue(parent_key)
Jira-->>PlanFeatureSkill: Parent issue (fields.issuetype.hierarchyLevel)
PlanFeatureSkill->>PlanFeatureSkill: [validate parent hierarchyLevel > Feature hierarchyLevel]
alt hierarchy valid
PlanFeatureSkill->>Jira: jira.edit_issue(feature_key, fields={parent:{key:parent_key}})
Jira-->>PlanFeatureSkill: parent link updated
PlanFeatureSkill->>User: confirm parent linked
else hierarchy invalid
PlanFeatureSkill->>User: inform hierarchy mismatch and re-prompt
end
else User presses Enter
PlanFeatureSkill->>User: skip Step1.5 and proceed to Step2
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- In Step 1.5, consider explicitly stating that the selected parent cannot be the same issue as the Feature (and ideally cannot create a cycle), so the validation step enforces a non-self, acyclic hierarchy in addition to the
hierarchyLevelcheck. - When describing the existing-parent flow in Step 1.5, it might help to clarify what happens if the user chooses to change the parent (e.g., whether the old parent link is overwritten unconditionally after successful validation of the new parent).
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In Step 1.5, consider explicitly stating that the selected parent cannot be the same issue as the Feature (and ideally cannot create a cycle), so the validation step enforces a non-self, acyclic hierarchy in addition to the `hierarchyLevel` check.
- When describing the existing-parent flow in Step 1.5, it might help to clarify what happens if the user chooses to change the parent (e.g., whether the old parent link is overwritten unconditionally after successful validation of the new parent).Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Eval Results
Eval Results: plan-feature
| Eval | Passed | Failed | Pass Rate |
|---|---|---|---|
| eval-1 | 11/16 | 5 | 69% |
| eval-2 | 8/14 | 6 | 57% |
| eval-3 | 9/15 | 6 | 60% |
| eval-4 | 6/11 | 5 | 55% |
| eval-5 | 8/15 | 7 | 53% |
| eval-6 | 6/14 | 8 | 43% |
Failed Assertions
eval-1: 5 failing assertions
-
Assertion: "After each task is created, a description digest comment is posted with a format-tagged SHA-256 hash — exactly 64 lowercase hex characters prefixed by 'sha256-md:' or 'sha256-adf:', not a placeholder, abbreviated value, or example string. Marker format: '[sdlc-workflow] Description digest: sha256-md:<64-char-hex>' (or sha256-adf). The digest is computed by re-fetching the description from the API and running scripts/sha256-digest.py"
Evidence: "None of the 4 task files or the impact-map.md contain any reference to SHA-256 hashes, digest comments, or the '[sdlc-workflow] Description digest:' marker. No separate files for digest comments exist in the outputs directory. The output directory contains only: impact-map.md, task-1-advisory-severity-model-and-service.md, task-2-advisory-summary-endpoint.md, task-3-cache-invalidation.md, task-4-integration-tests.md. No evidence of digest comment posting." -
Assertion: "Convention-aware enrichment validates file-type applicability per shared/convention-applicability-rules.md before including a convention — inapplicable conventions are excluded entirely (not listed with 'Not applicable' annotations), and applicable ones include a rationale in the prescribed format ('Applies: task modifies <file> matching the convention's <scope>'), not free-form prose"
Evidence: "None of the 4 task files contain any reference to CONVENTIONS.md, convention applicability, or the prescribed rationale format 'Applies: task modifies <file> matching the convention's <scope>'. The Implementation Notes sections reference docs/constraints.md (e.g., 'Per docs/constraints.md section 5 (Code Change Rules)') but contain no convention-aware enrichment. The repo-backend.md structure includes a CONVENTIONS.md file at the root, but no conventions from it appear in the task descriptions. No evidence of convention applicability validation occurring." -
Assertion: "When the Feature issue has a priority set (not 'Undefined'), every created task's additional_fields includes 'priority' with the inherited priority name. When the Feature's priority is 'Undefined', the priority key is omitted entirely from additional_fields (not set to null or 'Undefined')"
Evidence: "None of the 4 task files contain any reference to 'priority', 'additional_fields', or priority inheritance/propagation. The task descriptions contain only the standard template sections (Repository, Target Branch, Description, Files to Modify/Create, Implementation Notes, Acceptance Criteria, Test Requirements, Dependencies). No evidence of priority field handling." -
Assertion: "When the Feature issue has a non-empty fixVersions array and the fixVersion scope config (from ### Jira Field Defaults in CLAUDE.md) is 'task' or 'both' (or absent, defaulting to 'both'), every created task's additional_fields includes 'fixVersions' with the inherited version(s). When fixVersion scope is 'feature' or the Feature has no fixVersions, the fixVersions key is omitted entirely from additional_fields"
Evidence: "None of the 4 task files contain any reference to 'fixVersions', 'fixVersion', 'additional_fields', or version inheritance/propagation. No evidence of fixVersion field handling in any output file." -
Assertion: "The summary comment on the feature issue (Step 6c) includes the inherited priority and fixVersion values that were propagated to tasks, or states they were omitted and why"
Evidence: "No summary comment file exists in the outputs directory. The only files present are impact-map.md and 4 task description files. None of these files contain a summary comment section that mentions priority or fixVersion propagation. No evidence of a Step 6c summary comment."
eval-2: 6 failing assertions
-
Assertion: "Tasks document assumptions where they fill in missing details, labeled as assumptions pending clarification"
Evidence: "The impact map documents assumptions in the Ambiguity Analysis table with an 'Assumption' column header, but they are not labeled as 'pending clarification.' The individual task description files (task-1 through task-4) fill in missing details but do not label them as assumptions at all. For example, task-3 notes 'The feature requirement specifies some kind of filtering capability without detailing specific filters. This task adds the most commonly needed filters...' but does not label this as an assumption pending clarification. No output file uses the phrase 'pending clarification' or explicitly marks individual assumptions within task descriptions." -
Assertion: "After each task is created, a description digest comment is posted with a format-tagged SHA-256 hash — exactly 64 lowercase hex characters prefixed by 'sha256-md:' or 'sha256-adf:', not a placeholder, abbreviated value, or example string. Marker format: '[sdlc-workflow] Description digest: sha256-md:<64-char-hex>' (or sha256-adf). The digest is computed by re-fetching the description from the API and running scripts/sha256-digest.py"
Evidence: "None of the 5 output files (impact-map.md, task-1 through task-4) contain any reference to SHA-256 hashes, digest comments, 'sha256-md:', 'sha256-adf:', '[sdlc-workflow]', or 'Description digest'. No separate digest comment files exist in the outputs directory. The eval produced only impact-map.md and 4 task description files with no digest documentation." -
Assertion: "Convention-aware enrichment validates file-type applicability per shared/convention-applicability-rules.md before including a convention — inapplicable conventions are excluded entirely (not listed with 'Not applicable' annotations), and applicable ones include a rationale in the prescribed format ('Applies: task modifies <file> matching the convention's <scope>'), not free-form prose"
Evidence: "None of the 4 task description files contain any convention-aware enrichment. There are no 'Per CONVENTIONS.md' references, no 'Applies:' rationale lines, and no mention of CONVENTIONS.md or convention applicability anywhere in the Implementation Notes or elsewhere in any output file. The repo-backend.md indicates a CONVENTIONS.md exists in the repository, but the plan did not apply convention-aware enrichment to any task." -
Assertion: "When the Feature issue has a priority set (not 'Undefined'), every created task's additional_fields includes 'priority' with the inherited priority name. When the Feature's priority is 'Undefined', the priority key is omitted entirely from additional_fields (not set to null or 'Undefined')"
Evidence: "The feature TC-9002 has Priority: Normal (not Undefined), so every task should include priority propagation. However, none of the 4 task description files contain any reference to 'additional_fields', 'priority', 'Normal', or any Jira field inheritance/propagation. No separate output file documents priority propagation." -
Assertion: "When the Feature issue has a non-empty fixVersions array and the fixVersion scope config (from ### Jira Field Defaults in CLAUDE.md) is 'task' or 'both' (or absent, defaulting to 'both'), every created task's additional_fields includes 'fixVersions' with the inherited version(s). When fixVersion scope is 'feature' or the Feature has no fixVersions, the fixVersions key is omitted entirely from additional_fields"
Evidence: "The feature TC-9002 has Fix Versions: RHTPA 1.6.0 (non-empty). CLAUDE.md has no '### Jira Field Defaults' section, so fixVersion scope defaults to 'both', meaning fixVersions should propagate to tasks. However, none of the 4 task files contain any reference to 'fixVersions', 'additional_fields', 'RHTPA', or version propagation. No output file documents fixVersion inheritance." -
Assertion: "The summary comment on the feature issue (Step 6c) includes the inherited priority and fixVersion values that were propagated to tasks, or states they were omitted and why"
Evidence: "No summary comment file exists in the outputs directory. The impact map does not contain a summary comment section, and none of the output files mention priority propagation ('Normal') or fixVersion propagation ('RHTPA 1.6.0'). The outputs consist only of impact-map.md and 4 task description files with no Step 6c summary comment."
eval-3: 6 failing assertions
-
Assertion: "UI-facing frontend tasks (pages, components) reference Figma design context mentioning specific PatternFly components and visual specifications — API-layer frontend tasks (API types, client functions, hooks) are exempt from this requirement"
Evidence: "Task 3 (API types/hook) is API-layer and exempt. Task 4 (comparison page) extensively references Figma ('based on the Figma design', '(from Figma design)' multiple times) and PatternFly components (Select, ExpandableSection, Badge, Table, EmptyState, Skeleton, Dropdown, CodeBranchIcon) with visual specs (badge colors, critical highlight). However, Task 5 modifies the SbomListPage UI (adds checkbox selection column and 'Compare selected' button) — it mentions 'PatternFly's composable Table select pattern' but does NOT reference Figma design context. Since Task 5 modifies a page's UI, it is UI-facing, yet lacks Figma context." -
Assertion: "Cross-repo dependency ordering is enforced: either at least one frontend task explicitly depends on a backend task in its Dependencies section, or all tasks target a shared feature branch where backend tasks have lower task numbers than frontend tasks (implicit ordering via feature-branch workflow)"
Evidence: "No frontend task explicitly depends on a backend task. Task 3 Dependencies: 'None (API types can be built from the contract specification; backend endpoint existence is a deployment dependency, not a code dependency)'. Task 4 depends on Task 3 (frontend). Task 5 depends on Task 4 (frontend). For the alternative, all tasks target 'main' (direct-to-main workflow per impact-map.md), not a shared feature branch. 'main' is the default branch, not a feature branch, so the implicit ordering via feature-branch workflow does not apply." -
Assertion: "After each task is created, a description digest comment is posted with a format-tagged SHA-256 hash — exactly 64 lowercase hex characters prefixed by 'sha256-md:' or 'sha256-adf:', not a placeholder, abbreviated value, or example string. Marker format: '[sdlc-workflow] Description digest: sha256-md:<64-char-hex>' (or sha256-adf). The digest is computed by re-fetching the description from the API and running scripts/sha256-digest.py"
Evidence: "None of the 6 output files (impact-map.md, task-1 through task-5) contain any SHA-256 digest comment, '[sdlc-workflow] Description digest:' marker, or any reference to digest computation. No separate digest comment files exist in the outputs directory. There is zero evidence of digest comments being posted or documented." -
Assertion: "When the Feature issue has a priority set (not 'Undefined'), every created task's additional_fields includes 'priority' with the inherited priority name. When the Feature's priority is 'Undefined', the priority key is omitted entirely from additional_fields (not set to null or 'Undefined')"
Evidence: "None of the 5 task description files contain any mention of 'additional_fields', 'priority', or priority propagation. The impact-map.md also contains no priority information. There is no evidence in any output file that priority was considered, inherited, or propagated to tasks." -
Assertion: "When the Feature issue has a non-empty fixVersions array and the fixVersion scope config (from ### Jira Field Defaults in CLAUDE.md) is 'task' or 'both' (or absent, defaulting to 'both'), every created task's additional_fields includes 'fixVersions' with the inherited version(s). When fixVersion scope is 'feature' or the Feature has no fixVersions, the fixVersions key is omitted entirely from additional_fields"
Evidence: "None of the 5 task description files contain any mention of 'additional_fields', 'fixVersions', or version propagation. The impact-map.md also contains no fixVersion information. There is no evidence in any output file that fixVersions was considered, inherited, or propagated to tasks." -
Assertion: "The summary comment on the feature issue (Step 6c) includes the inherited priority and fixVersion values that were propagated to tasks, or states they were omitted and why"
Evidence: "No summary comment file exists in the outputs directory. The impact-map.md contains a Task Summary table but no mention of priority or fixVersion propagation. None of the 6 output files contain any summary comment about inherited priority or fixVersion values, nor any explanation of why they were omitted."
eval-4: 5 failing assertions
-
Assertion: "After each task is created, a description digest comment is posted with a format-tagged SHA-256 hash — exactly 64 lowercase hex characters prefixed by 'sha256-md:' or 'sha256-adf:', not a placeholder, abbreviated value, or example string. Marker format: '[sdlc-workflow] Description digest: sha256-md:<64-char-hex>' (or sha256-adf). The digest is computed by re-fetching the description from the API and running scripts/sha256-digest.py"
Evidence: "No digest comments found anywhere in the output files. The outputs directory contains only impact-map.md and 6 task files (task-1 through task-6). None of these files contain '[sdlc-workflow] Description digest:', 'sha256-md:', 'sha256-adf:', or any SHA-256 hash strings. No separate digest comment files exist in the outputs directory." -
Assertion: "Convention-aware enrichment validates file-type applicability per shared/convention-applicability-rules.md before including a convention — inapplicable conventions are excluded entirely (not listed with 'Not applicable' annotations), and applicable ones include a rationale in the prescribed format ('Applies: task modifies <file> matching the convention's <scope>'), not free-form prose"
Evidence: "No convention-aware enrichment is present in any of the 6 task files. None of the task descriptions contain 'Per CONVENTIONS.md', 'Applies:', or any convention applicability rationale text. The target repository (trustify-backend) has a CONVENTIONS.md file listed in its directory tree (repo-backend.md line 15), which means conventions exist that should have been evaluated for applicability. The Implementation Notes sections in all tasks reference code patterns and file paths but contain zero convention references with the prescribed rationale format." -
Assertion: "When the Feature issue has a priority set (not 'Undefined'), every created task's additional_fields includes 'priority' with the inherited priority name. When the Feature's priority is 'Undefined', the priority key is omitted entirely from additional_fields (not set to null or 'Undefined')"
Evidence: "The Feature issue TC-9004 has Priority set to 'Major' (feature-adversarial.md line 6). Therefore every created task should include additional_fields with priority 'Major'. However, none of the 6 task files contain 'additional_fields', 'priority', or 'Major' anywhere in their content. The priority was not propagated to any task." -
Assertion: "When the Feature issue has a non-empty fixVersions array and the fixVersion scope config (from ### Jira Field Defaults in CLAUDE.md) is 'task' or 'both' (or absent, defaulting to 'both'), every created task's additional_fields includes 'fixVersions' with the inherited version(s). When fixVersion scope is 'feature' or the Feature has no fixVersions, the fixVersions key is omitted entirely from additional_fields"
Evidence: "The Feature issue TC-9004 has Fix Versions set to 'RHTPA 1.5.0' (feature-adversarial.md line 7). The project CLAUDE.md does not contain a '### Jira Field Defaults' section, so the fixVersion scope defaults to 'both', meaning fixVersions should be propagated to tasks. However, none of the 6 task files contain 'additional_fields', 'fixVersions', or 'RHTPA 1.5.0' anywhere in their content. The fixVersions were not propagated to any task." -
Assertion: "The summary comment on the feature issue (Step 6c) includes the inherited priority and fixVersion values that were propagated to tasks, or states they were omitted and why"
Evidence: "No summary comment file exists in the outputs directory. The outputs contain only impact-map.md and 6 task files (task-1 through task-6). None of these files contain a summary comment section referencing Step 6c, priority propagation ('Major'), fixVersion propagation ('RHTPA 1.5.0'), or any explanation of omission. No file documents the summary of what was propagated to tasks."
eval-5: 7 failing assertions
-
Assertion: "Each task file contains all required template sections: Repository, Target Branch, Description, at least one of Files to Modify or Files to Create, Implementation Notes, Acceptance Criteria, Test Requirements"
Evidence: "Intermediate tasks (2-6) all contain every required section. However, bookend tasks fail: task-1-create-feature-branch.md has no 'Files to Modify', 'Files to Create', or 'Implementation Notes' sections. task-7-merge-feature-branch.md similarly has no 'Files to Modify', 'Files to Create', or 'Implementation Notes' sections. The assertion says 'Each task file' without exception." -
Assertion: "The plan includes a workflow:feature-branch label decision to be applied to the feature issue"
Evidence: "No mention of a 'workflow:feature-branch' label appears anywhere in the output files. The impact-map.md states 'Workflow Mode:feature-branch' as a heading but does not reference applying a label to the feature issue. Grep across all output files for 'label' returned zero matches." -
Assertion: "After each task is created, a description digest comment is posted with a format-tagged SHA-256 hash — exactly 64 lowercase hex characters prefixed by 'sha256-md:' or 'sha256-adf:', not a placeholder, abbreviated value, or example string. Marker format: '[sdlc-workflow] Description digest: sha256-md:<64-char-hex>' (or sha256-adf). The digest is computed by re-fetching the description from the API and running scripts/sha256-digest.py"
Evidence: "No output file contains any mention of 'digest', 'sha256', '[sdlc-workflow]', or any hash values. There are no separate files documenting digest comment operations. Grep across all outputs for 'sha256' and 'digest' returned zero matches." -
Assertion: "Convention-aware enrichment validates file-type applicability per shared/convention-applicability-rules.md before including a convention — inapplicable conventions are excluded entirely (not listed with 'Not applicable' annotations), and applicable ones include a rationale in the prescribed format ('Applies: task modifies <file> matching the convention's <scope>'), not free-form prose"
Evidence: "No output file contains any mention of 'convention', 'applicab', or the prescribed rationale format 'Applies: task modifies'. There is no evidence of convention-aware enrichment or validation in any task file." -
Assertion: "When the Feature issue has a priority set (not 'Undefined'), every created task's additional_fields includes 'priority' with the inherited priority name. When the Feature's priority is 'Undefined', the priority key is omitted entirely from additional_fields (not set to null or 'Undefined')"
Evidence: "No output file contains any mention of 'priority', 'additional_fields', or any priority propagation logic. Grep across all outputs for 'priority' returned zero matches." -
Assertion: "When the Feature issue has a non-empty fixVersions array and the fixVersion scope config (from ### Jira Field Defaults in CLAUDE.md) is 'task' or 'both' (or absent, defaulting to 'both'), every created task's additional_fields includes 'fixVersions' with the inherited version(s). When fixVersion scope is 'feature' or the Feature has no fixVersions, the fixVersions key is omitted entirely from additional_fields"
Evidence: "No output file contains any mention of 'fixVersion', 'fixVersions', 'additional_fields', or version propagation. Grep across all outputs for 'fixVersion' returned zero matches." -
Assertion: "The summary comment on the feature issue (Step 6c) includes the inherited priority and fixVersion values that were propagated to tasks, or states they were omitted and why"
Evidence: "No output file contains a summary comment or any mention of a summary comment being posted to the feature issue. There is no file documenting priority or fixVersion propagation in a summary. Grep across all outputs for 'summary comment' returned zero matches."
eval-6: 8 failing assertions
-
Assertion: "Each task specifies its parent Epic key in the output — tasks targeting trustify-backend are assigned to the backend Epic, tasks targeting trustify-ui are assigned to the frontend Epic"
Evidence: "The individual task files (task-1 through task-6) do not contain any parent Epic key field. The impact-map.md table maps tasks to epics (Tasks 1-3 to 'TC-9006: trustify-backend', Tasks 4-6 to 'TC-9006: trustify-ui'), but the task description files themselves have no Epic key reference. No epic issue keys (e.g., TC-9007, TC-9008) are mentioned in any task file." -
Assertion: "Incorporates links are created from the Feature to each Epic (not from Feature to individual Tasks)"
Evidence: "No output file contains any mention of 'Incorporates' links, issue linking, or link creation from the Feature to Epics. The impact-map.md describes epic grouping but does not document link creation. No separate file documents Jira link operations." -
Assertion: "Epics are created with the level-1 issue type name ('Epic') and parent set to the feature issue key"
Evidence: "No output file documents the issue type name used for epic creation or the parent field. The impact-map.md mentions epics by summary name but does not specify the Jira issue type name ('Epic') or parent configuration. No separate epic creation output exists." -
Assertion: "After each task is created, a description digest comment is posted with a format-tagged SHA-256 hash — exactly 64 lowercase hex characters prefixed by 'sha256-md:' or 'sha256-adf:', not a placeholder, abbreviated value, or example string. Marker format: '[sdlc-workflow] Description digest: sha256-md:<64-char-hex>' (or sha256-adf). The digest is computed by re-fetching the description from the API and running scripts/sha256-digest.py"
Evidence: "No output file contains any SHA-256 hash, 'sha256-md:', 'sha256-adf:', 'Description digest', or '[sdlc-workflow]' marker. None of the 7 output files (impact-map.md and 6 task files) document digest comment posting. No separate digest comment files exist in the outputs directory." -
Assertion: "Convention-aware enrichment validates file-type applicability per shared/convention-applicability-rules.md before including a convention — inapplicable conventions are excluded entirely (not listed with 'Not applicable' annotations), and applicable ones include a rationale in the prescribed format ('Applies: task modifies <file> matching the convention's <scope>'), not free-form prose"
Evidence: "No task file contains any convention references, 'Per CONVENTIONS.md' citations, 'Applies:' rationale lines, or any evidence of convention-aware enrichment. The Implementation Notes sections in all 6 task files contain implementation guidance but no convention applicability validation or prescribed-format rationale. There is no evidence that the convention enrichment process was executed." -
Assertion: "When the Feature issue has a priority set (not 'Undefined'), every created task's additional_fields includes 'priority' with the inherited priority name. When the Feature's priority is 'Undefined', the priority key is omitted entirely from additional_fields (not set to null or 'Undefined')"
Evidence: "No task file contains an 'additional_fields' section or any mention of priority inheritance. The word 'priority' does not appear in any of the 6 task description files. There is no evidence that priority propagation from the Feature issue was considered or implemented." -
Assertion: "When the Feature issue has a non-empty fixVersions array and the fixVersion scope config (from ### Jira Field Defaults in CLAUDE.md) is 'task' or 'both' (or absent, defaulting to 'both'), every created task's additional_fields includes 'fixVersions' with the inherited version(s). When fixVersion scope is 'feature' or the Feature has no fixVersions, the fixVersions key is omitted entirely from additional_fields"
Evidence: "No task file contains an 'additional_fields' section or any mention of fixVersions. The term 'fixVersion' does not appear in any of the 6 task description files. There is no evidence that fixVersion propagation was considered or implemented." -
Assertion: "The summary comment on the feature issue (Step 6c) includes the inherited priority and fixVersion values that were propagated to tasks, or states they were omitted and why"
Evidence: "No output file contains a summary comment for the feature issue. There is no file documenting Step 6c output, no mention of inherited priority or fixVersion values in any output file, and no explanation of omission. The outputs directory contains only the impact map and 6 task description files."
Pass rate: 56% · Tokens: 65,059 · Duration: 232s
Baseline (d573976e): 56% · 60,925 tokens · 210s
Generated by sdlc-workflow/run-evals v0.11.1
|
[sdlc-workflow/verify-pr] Re: @sourcery-ai[bot] review — 2 items classified:
|
Verification Report for TC-4870 (commit eef8892)
Overall: PASSAll checks pass. The PR correctly adds Step 1.5 (Link Feature to Parent Issue) to plan-feature with hierarchy validation, REST API fallback, and constraint 1.82 with traceability index update. Two reviewer suggestions (self-reference/cycle check and overwrite behavior clarification) were classified as suggestions with no convention backing — no sub-tasks created. This comment was AI-generated by sdlc-workflow/verify-pr v0.11.1. |
1 participant
Summary
hierarchyLevelis strictly higher than the Feature's before setting the linkjira.edit_issue(id, parent)and include Step 1.5 in the JIRA operations listdocs/constraints.mdwith traceability index updateImplements TC-4870
Test plan
hierarchyLevelcomparison (parent must be strictly higher)jira-client.py update_issuepatternplan-feature/SKILL.md — Step 1.5🤖 Generated with Claude Code
Summary by Sourcery
Introduce an optional step in the plan-feature workflow to link a Feature to a validated parent issue in the Jira hierarchy, with supporting REST fallback and documentation updates.
New Features:
Enhancements:
Documentation: